[Previous] [Next] [Index] [Thread]

what are realistic threats?

Thanks for the reply.  Let's continue the discussion further ...

   A certificate asserts a property of a public key and is signed by
   other public keys. A lot of different things get lumped into
   revocation:
   ...

Do you not think that key pairs might be "routinely" regenerated, just
like a user password should be changed periodically?  I.e., you may
not know that your private key has been compromised; perhaps it was
just copied from your local disk, etc.  This seems true especially
since digital signatures will be a primary application of public key
mechanisms, with a fair amount of trust associated with those signatures.

   Perhaps the difference between (2) and (3) isn't important, but certainly
   the difference between key revocation and certificate revocation is.
   It is natural for certificates to include some mechanism for their
   revocation. E.g. x.509 certificates have an implicit mechanism by looking
   at well defined attributes in the X.500 entry for the certificate signer. 

Agreed.

   ...
   a particular key has such a certificate. In fact there aren't likely to
   be many cases of key revocation and a simple single flat database replicated
   by flooding would do the trick. Trouble is this would be liable to denial
   of service attacks by generating lots of revocation certificates. Perhaps
   this could be handled by charging, or maybe some more sophisticated
   distributed directory system is needed.

I wouldn't assume that "there aren't likely to be many cases of key
revocation", at least in terms of defining solutions to the problem.
IMHO, I think a distributed directory system (of some sort) will be
necessary. 

   I agree that there are some applications where an on-line check of
   the status of a key might be needed. But certainly not for the small
   amounts of money that will be needed for purchasing most information
   through the WWW. On the other hand if you are buying something physical
   which has to be physically delivered then an on-line check is again
   not needed, as long as the check is made sometime before final delivery.

Hmmm ... it seems that even for small purchases, the service provider
would want some reasonable assurance that the user's claimed ID is
indeed authentic, at least for certain payment mechanisms (electronic
check, credit card, etc.).  An analogy would be having to show a
picture ID (e.g. a drivers license) when writing a check or using your
credit card at a store.  Given the "faceless" nature of the network, 
a user's digital signature and corresponding certificate (signed by a
certification authority) would be akin to their hand written signature
and photo ID (with signature).

Now, I'm also aware of other payment scenarios which only authenticate
the service, not the user.  E.g., the user simply provides a credit
card number when purchasing something.  I guess this is analagous to
just providing a credit card number with an order over the phone.

Also, wrt "physical" items, wouldn't a provider want to verify the
user early on in the ordering process?  I.e., *before* payment is
received and the goods are shipped?


- Doug
References: